Drop no-longer-used gtkrc files

These were replaced by css files long ago.

Drop a pointless function

No need to have a finalize function if it just chains
up to the parent class.

Trivial: slight code rearrangement

tests: Stop using GtkAlignment

Fix up all other tests to not use GtkAlignment anymore.

testadjustsize: Keep using an alignment

We are explicitly comparing GtkAlignment with its replacements
here.

gtk-demo: Drop use of GtkAlignment

Deprecate GtkAligment

This has been dangling ever since 3.0.

https://bugzilla.gnome.org/show_bug.cgi?id=645781

Drop an unneeded include

There's no GtkGesture in gtkwidget.h anymore. We do need an include
in gtkwidgetprivate.h though.

a11y: build directly into libgtk instead of an internal library

https://bugzilla.gnome.org/show_bug.cgi?id=730615

More updates

Some updates

Updated POTFILES.in

Merge branch 'gestures'

spinbutton: Avoid touch text handles to pop up

Those get in the middle more than help on these widgets, the widget
is already packed with clickable areas and having handles (and their
invisible clickable area around) hovering above don't help, plus the
purpose in most likely numeric values is a bit doubtful.

All touch events are either consumed by the up/down panels, or
the swipe gesture, all GtkEntry handling of touch events on the text
window is avoided, so handles to not appear anymore.

colorswatch: Set gestures in GTK_PHASE_TARGET

That's the right phase for gestures replacing entirely event handlers.

spinbutton: Use GTK_PHASE_CAPTURE for touch swipes

The gesture must be able to catch first events for it to be seen
as recognized in event handlers.

widget: Flip execution order of GTK_PHASE_TARGET/BUBBLE

the "bubble" phase used to run before event handlers before GTK_PHASE_TARGET
was added, in order to keep phases in the expected order, move GTK_PHASE_BUBBLE
to be run (still invariably) after event handlers.

The only behavioral change should be wrt widgets wanting mixed event handler/
gesture handling, they could previously attach the gesture to the bubble phase
and check for gtk_gesture_is_active() in the event handler to bail out, they'll
have to use GTK_PHASE_CAPTURE for that purpose from now on.

texthandle: Mind the invisible area when moving the handle

The handle is still centered horizontally, but the extra vertical
space wasn't taken into account, leading to misplacing the dragging
point (and the handle) during motion events.

textview: Check first whether the sequence is handled, fetch later the event

And always unset/hide the selection popover if unhandled, that means the
sequence went grabbed/claimed somewhere else and cancelled here.

entry: Check first whether the sequence is handled, fetch later the event

And always unset/hide the selection popover if unhandled, that means the
sequence went grabbed/claimed somewhere else and cancelled here.

gesture: Use GdkEventSequence GType in signals

gesture: Introspection fixes

Set annotations on return values for gtk_gesture_get_device() and
gtk_gesture_get_window().

eventcontroller: introspection fix

Set transfer annotation on gtk_event_controller_get_widget()

gdk: Make GdkEventSequence a boxed type

Not much to copy nor free, but this'll make bindings happy

paned: Handle pointer events from touchscreen devices

GtkPaned may just capture pointer events because the child widget
doesn't happen to have GDK_TOUCH_MASK set, resort to checking the
device in that case.

Docs: Cosmetic fixes

docs: Correct a reference

Revert "docs: GtkEventController was dropped from public api"

This reverts commit eefac03b395a6b885fd61c100b48652200beb996.

Revert "docs: More GtkEventController removal"

This reverts commit 75f503fb1fc9068c9e1a0d02126c55addbe8eb3e.

Docs: Add information about event propagation

Docs: Minor changes

Document gtk_gesture_set_state

docs: gtk_gesture_cancel_sequence was made private

docs: More GtkEventController removal

docs: GtkEventController was dropped from public api

paned: Use GtkGesture to handle handle dragging

Dragging is all handled by a GtkGesturePan now, matching the
paned orientation.

On touch events, a wider area is listened for, so touch events
don't need to be as accurate to initiate dragging, if no dragging
is truly initiated in this case, events are just forwarded for
child widgets to handle.

switch: Use GtkGesture to handle input events

A pan gesture is used to handle switch dragging, which is only triggered
by horizontal panning movements. A multipress gesture handles the cases
where clicking without dragging happens, just toggling the switch.

inspector: Add more complete gesture support

Add a dedicated tab that shows how gestures are grouped,
and allows changing the propagation phase.

inspector: Minimal support for gestures

We're just showing them as objects in the tree, for now.

Add back a private api to list controllers

This will let us show them in the inspector.

texthandle: Make a bigger hit area around texthandles

The hit area now extends to all sides around the handle, instead
of just towards where the text is. This makes it easier to grab
handles once shown.

gesture: Declare GtkGesture:window as an object property

widget: 3-way merge ate my g_object_ref()

Move it to the right place.

scrolledwindow: Handle directional cancellation if there is a single scroll direction

A pan gesture is optionally attached if there is only one scrolling direction, the pan
gesture orientation is changed so movements tangential to the scroll direction get
scrolling cancelled (The pan gesture is automatically denied when that happens, and
that state change spreads to the others gestures in the group). If the pan direction
happens in the expected directions, no cancellation happens, and scrolling eventually
takes place.

widget: remove check on whether the controller was already added

Multiple calls are supposedly allowed to change the phase (although
unlikely to happen), so remove the g_return_if_fail() checking whether
the controller was already added.

pan: Remove wrong check

From the very early days where there were a NONE=0 GtkPanOrientation
value. This makes vertical pan operations work as expected.

entry: Ensure the cursor text handle is shown after touching to reposition cursor.

popover: Hide widget first when disposing

In order to ensure invariants are kept.

entry: Obey implementations' frame when placing handles/popovers around

Y=0 was assumed in a few places, not necessarily right on eg. vertical
spinbuttons.

entry: Improve touch popover interaction

Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)

textview: Show the magnifier popover a bit farther from the touch position

Somewhat arbitrary at the moment, would be nice to have minimal units
support for this, or at least hidpi support.

textview: Improve touch popover interaction

Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)

entry: Use gestures to handle pointer/touch events

Similarly to GtkTextView, a GtkGestureMultiPress gesture handles
button/touch presses to initiate one selection mode or other, and
a GtkGestureDrag is used to handle text selection and DnD checks.

The code from button press/release, motion, and grab_notify handlers
has been shuffled into the actions triggered by those gestures.

spinbutton: Attach "swipe to spin" controllers to the bubble phase

It is unnecessary to have those process events manually, just attach
those to the bubble phase.

colorplane: Fully port to GtkGesture

A GtkGestureDrag is used for color selection, removing also the
need to track the pointer state in widget data. The GDK grab performed
just to set the crosshair cursor has been replaced by a call
to gdk_window_set_device_cursor(), which will be unset if the
drag operation is finished, or cancelled due to the implicit grab
being broken.

gdk: Lookup both device and global cursor when checking up the hierarchy

When the pointer cursor is updated on CSW, lookup for either a device
cursor, or a global one. It would previously lookup for windows with
a global cursor, and then check if it had a device cursor, which would
skip windows with only device cursors set, and unexpectedly set the
global cursor.

button: Make multipress gesture exclusive

We only want actions to be triggered by a single sequence there,
so buttons trigger no actions on further simultaneous touches
happening.

gesturesingle: Add an "exclusive" boolean property

All "exclusive" gestures listen for either pointer events, or
"pointer emulating" touch events, so only a single sequence at
a time can make these run.

button: Use GtkGestureMultiPress for signal emission

It is now useful for that purpose with a ::release signal, so replace
the custom GtkGestureSingle with one of these.

drag: Allow gtk_gesture_get_start_point/offset() to be called on ::drag-end

multipress: Add matching ::released signal

This signal will always be paired with a ::pressed signal, unless
the sequence is cancelled, or the controller is reset. the n_press
argument in the signal always matches the ::press signal one, even
if GtkGestureMultiPress::stopped was emitted in between.

multipress: Protect against fleeting touches mistriggering events

The current sequence (as per gtk_gesture_single_get_current_sequence)
is used to find out the coordinates. And only emit ::pressed if the
gesture began through a GDK_BUTTON_PRESS/TOUCH_BEGIN (eg. not due to
an extra touch being lifted)

textview: Set up controllers on the GTK_PHASE_TARGET propagation phase

This way events are managed by gestures in the event handlers themselves,
respecting the execution order already assumed by subclasses around.

widget: Hook GTK_PHASE_TARGET controllers to the default event handlers

Just call the controllers on that phase if the default widget handlers
are run.

For compatibility reasons, in the touch event handler, let the pointer
emulating touch be transformed to a pointer event as usual, in order to
have widget handlers a chance to run at all. If they have to be managed
by a controller in that phase, it'll have to be through the default pointer
event handlers.

gesture: Add GTK_PHASE_TARGET

This phase is meant to run in the default widget handlers, as opposed
to externally as in the bubble/capture phase. This will be most usually
the expected phase for every controller replacing code in event handlers
in GTK+, just so invocation and triggering order is kept unaltered.

gesture: Handle GdkEventGrabBroken

That may happen separately from grab-notify, and also due to external
reasons, so ensure all sequences are cancelled if a grab is taken
in some GdkWindows that would obscure events on the controller.

GtkColorSwatch: Use gesture for button events too

GtkWindow: Only use a multipress gesture for toplevels

There is no point in creating and attaching this gesture
for override-redirect windows, so don't do it.

Be careful about the list of event controllers

We can end up with _gtk_widget_remove_controller getting called
while we are iterating over the list in _gtk_widget_run_controllers.
To avoid trouble, only mark the event controller as dead by
setting data->controller to NULL, and defer the actual freeing
and list manipulation to the loop in _gtk_widget_run_controllers.
Update other places that operate on controllers to handle
data->controller being NULL.

textview: Convert gestures' coordinates to text window ones

And make some code shared between multipress/drag gesture.

textview: Use GtkGestureDrag for text selection/DnD

remaining code in button press/release, motion notify, and grab
notify handlers has been shuffled to be managed by this gesture.

textview: Use GtkGestureMultiPress for click handling

The button press handler is no longer necessary, and most of its
code has been shuffled into the GtkGestureMultiPress::pressed
handler.

widget: tighten the conditions at which a press event is emulated

Make it really sure that the event is only emitted after every gesture
that consumed the button press is done with the sequence.
The event must only be emulated if a gesture in the capture phase happened
to consume the event, be cancelled, and

widget: Fix gesture event handler retval for bubbled events

Do not clobber the return value if the regular event handler happens
to return FALSE, even if the gesture meant to consume the event.

gesture: Prevent against sequence cancellation within gtk_gesture_set_state()

Sequences may be cancelled within the ::sequence-state-changed handler, which
would change the points hashtable as it's being iterated in this function. So
iterate over a list of sequences and let the hashtable change freely.

gesture: Make gtk_gesture_get_last_update_time() private

gesture: Remove gtk_gesture_get_last_event_type

gesture: make gtk_gesture_cancel_sequence() private

gesture: Make gtk_gesture_check() private

dnd: Check on the right gesture sequence when starting the drag op

gesture: Simplify gesture/widget interaction public API

The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.

The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.

All callers have been updated.

widget: Keep a widget reference around _gtk_widget_run_controllers()

The widget may be destroyed within the loop, in reaction to the signals
sent by the controllers. Protect against that.

gesture: Add explanatory note in GtkGesture::end

Explain that this signal may be triggered by an extra touch that causes
the gesture to surpass GtkGesture:n-points.

gesture: Cancel sequences that make a gesture exceed the number of touches as they happen

This makes it possible to track those through gtk_gesture_handles_sequence(),
without guessing from last event type or sequence state.

widget: Change slightly the gesture cancellation policy in a same widget

Within a widget, if a gesture accepts a sequence, it would previously
cancel every other gesture that not in the same group. Change this to
only cancelling gestures that previously claimed the gesture, and let
gestures with state=NONE for that sequence remain like that.

This enables late recognition of gestures, even on the presence of
another gesture group that was more eager at claiming the gesture.

One usecase is user-defined panning gestures on scrolledwindows,
if ::capture-button-press is TRUE (eg. the default), the gesture is
claimed early in order to consume the button press, but that would
tipically make every other gesture group deny the sequence. With
this change, the pan gesture can keep state=NONE, and later claim
the sequence for itself if the panning gesture is recognized.

Also, do not propagate state=DENIED to every gesture in the widget,
that was unintended.

rotate: Ensure delta is between [0..2π]

pan: make the direction factor less narrow in v/h directions

gesture: Handle GDK_TOUCH_CANCEL events

The wayland windowing backend emits such events for instance, so
have gestures cancel the sequence as those events get through.

gesture: Protect against odd window hierarchies

If no match is found with the gesture widget when poking the event
window parents, bail out safely instead of falling in an infinite
loop. This was seen on Mutter.

swipe: Don't emit ::swipe if there are still active touches

Avoids sending spurious signals when an extra touch happens.

Prevent subclassing of gestures

For now, at least. We do this by hiding the instance and
class structures in private headers.

GtkSpinButton: Don't leak the gestures

GtkWindow: Don't leak the gesture

GtkTreeView: Remove unused field

gtk3-demo: Don't leak the color chooser

GtkColorPlane: Actually add the long press gesture

This was missed because gtk_widget_remove_controller silently
does nothing on unowned controllers.

GtkButton: Don't leak the gesture

Forgotten file

GtkButton: Port to GtkGesture

Quick-and-dirty patch to use a GtkGestureSingle for both
button press/release and touch event handling.

widget: remove GtkGesture-related signals

The utility of those signals is somewhat dubious now that there is
gtk_gesture_group(), so make that the only way to coordinate gestures.
The cooperation model offered by gtk_gesture_group() is flexible
enough,